Systems and methods for device-assisted seamless transfer between edge computing systems in a wireless network

ABSTRACT

A system described herein may provide a technique for the seamless transfer of services provided by a first Multi-Access/Mobile Edge Computing device (“MEC”) to a User Equipment (“UE”), to a second MEC. Context information associated with a given application for which services are provided by the first MEC may be cached by the UE based on a determination that the second MEC should provide the services, and the UE may provide the cached information to the second MEC in order to seamlessly continue receiving services. The providing of the cached information to the UE and/or to the second MEC may be performed with an elevated priority level, in order to facilitate the seamless providing of the services relating to the application, thus resulting in minimal to no interruption of the user experience associated with the application.

BACKGROUND

Wireless user equipment (“UE”), such as mobile telephones or otherwireless communication devices, may communicate with application serversvia a wireless network, which may include one or more radio accessnetworks (“RANs”), such as a Long-Term Evolution (“LTE”) RAN, a FifthGeneration (“5G”) RAN, or some other type of RAN. Wireless networks maymake use of Multi-Access/Mobile Edge Computing (“MEC”) devices, referredto sometimes herein simply as “MECs,” which may be located atgeographically diverse locations within a given wireless network. MECsmay perform computing for applications executing at UEs connected to thewireless network, such that traffic associated with such applicationsdoes not need to traverse a core of the wireless network and/or one ormore external networks.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example overview of one or more embodimentsdescribed herein;

FIG. 2 illustrates example components of one or more devices or systemsand their respective communication pathways, in accordance with one ormore embodiments described herein;

FIG. 3 illustrates an example signal flow that may be used for aseamless transfer between MECs, in accordance with some embodiments;

FIG. 4 illustrates an example process for a seamless transfer betweenMECs, in accordance with some embodiments;

FIG. 5 illustrates an example environment in which one or moreembodiments, described herein, may be implemented;

FIG. 6 illustrates an example arrangement of a RAN, in accordance withsome embodiments;

FIG. 7 illustrates an example arrangement of an Open RAN (“O-RAN”)environment in which one or more embodiments, described herein, may beimplemented; and

FIG. 8 illustrates example components of one or more devices, inaccordance with one or more embodiments described herein.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

MECs may be geographically distributed devices or systems that performcomputing, calculations, processing, and/or other operations associatedwith applications executing at one or more UEs, such as mobile phones,tablets, Machine-to-Machine (“M2M”) devices, Internet of Things (“IoT”)devices, autonomous vehicles, or the like. The performance of suchcomputing, calculations, processing, etc. by MECs as opposed to “farcloud” resources such as Internet-accessible application servers orother types of resources may result in reduced latency and/or otherwiseenhanced performance as compared to the use of “far cloud” resources forthese operations.

In order to provide services to UEs (e.g., in relation to applicationsexecuted by the UEs), such as stateful services, MECs may maintaincontext data, application state data, etc. (referred to herein simply as“context data”) based on which the MECs may perform computations,calculations, etc. related to such services. For example, for a MECproviding services related to autonomous driving, the MEC may maintaintelemetry data received over a rolling time window from a givenautonomous vehicle, based on which the MEC may determine outputinformation such as throttle control parameters, brake controlparameters, steering control parameters, or the like. As anotherexample, for a MEC providing services related to an augmented reality(“AR”) application, the MEC may maintain a buffer of audio and/or videoinformation received from the UE over time, and may generate graphicaloverlays and/or other information to the UE to provide a suitable ARexperience. As yet another example, for a MEC providing services relatedto a video game, the MEC may maintain a game state, such as level, livesremaining, location within a game world, and/or other suitableinformation, may generate output information (e.g., graphics, audio,haptic feedback, etc.) based on the game state, and may provide theoutput information to the UE.

In some situations, a new MEC (e.g., a “target” MEC) may be selected,assigned, etc. for a UE that is currently served by another MEC (e.g., a“source” MEC). For example, the UE may travel between differentgeographical regions that are served by different MECs, one MEC mayoffer better performance (e.g., lower latency, lower processing times,etc.) than another MEC, one MEC may be more loaded than another MEC,etc. In such situations, the target MEC may not have access to thecontext information associated with an application for which servicesare provided to the UE by the source MEC. Without such information, thetarget MEC may be unable to provide stateful services associated withthe application to the UE.

As described herein, context information associated with a givenapplication (or set of applications) for which services are provided bya MEC (e.g., a “source” MEC) to a UE may be cached by the UE based on adetermination that the UE is moving to a geographical region serviced bya different MEC (e.g., a “target” MEC), and the UE may provide thecached information to the target MEC in order to seamlessly continuereceiving services associated with the application. In some embodiments,the providing of the cached information to the UE (e.g., by the sourceMEC) and/or to the target MEC (e.g., by the UE) may be performed with anelevated priority level, in order to facilitate the seamless providingof the services relating to the application, thus resulting in minimalto no interruption of the user experience associated with theapplication.

As shown in FIG. 1, for example, UE 101 may be located within a firstgeographical region 103-1. In this example geographical region 103-1 maybe associated with a first MEC 105-1, and geographical region 103-2 maybe associated with a second MEC 105-2. For example, geographical region103-1 may be served by a first base station of a RAN (e.g., an evolvedNode B (“eNB”), a Next Generation Node B (“gNB”), and/or some other typeof base station), and geographical region 103-2 may be served by asecond base station of the RAN. Additionally, or alternatively,geographical region 103-1 may be a first sector associated with aparticular base station, and geographical region 103-2 may be a secondsector associated with the same base station. In some embodiments, MECs105 may be associated with respective geographical regions 103 in someother suitable manner.

While illustrated in FIG. 1 as a mobile phone, as noted above, UE 101may be, may include, and/or may be included as a component of one ormore other devices or systems. For example, UE 101 may be, may include,and/or may be included as a component of an IoT device, an M2M device,an autonomous vehicle, and/or some other type of device with networkcommunication capabilities.

As noted above, UE 101 may execute one or more network applications thatcommunicate, via a RAN or some other suitable type of access network,with MEC 105-1. For example, as noted above, UE 101 may communicate withMEC 105-1 via a particular base station of a RAN with which MEC 105-1 isassociated. Additionally, or alternatively, MEC sync controller 107and/or one or more other devices or systems may have selected MEC 105-1,from a set of candidate MECs 105, based on a location of UE 101 withingeographical region 103-1 associated with MEC 105-1, and/or based on oneor more other criteria. MEC sync controller 107 may include, and/or maybe communicatively coupled to, a device or system that receives locationinformation associated with UE 101 (e.g., from UE 101 directly, from abase station to which UE 101 is connected, and/or from one or more otherdevices or systems) and selects a particular MEC 105 to provide servicesassociated with applications executed by UE 101 based on the location ofUE 101 and/or other factors.

Based on the location of UE 101 being within geographical region 103-1associated with MEC 105-1, and/or based on one or more other factors, UE101 may send and/or receive (at 102) application data associated withone or more applications executing at UE 101 and served by MEC 105-1.For example, UE 101 may send sensor data, such as recordings ormeasurements associated with one or more accelerometers, gyroscopes,photosensors, cameras, microphones, Light Detection and Ranging(“LIDAR”) devices, barometers, particulate matter sensors, and/or othertypes of sensors, input devices, measurement devices, or the like to MEC105-1. In some embodiments, the application data may include user inputdata, such as voice input, keyboard input, haptic input, etc. providedby one or more users to UE 101.

At some point while communications (at 102) between UE 101 and MEC 105-1are ongoing, UE 101 may move (at 104) toward and/or into geographicalregion 103-2, associated with MEC 105-2. For example, UE 101 may belocated in, may be installed in, etc. an autonomous vehicle travelingalong a roadway. MEC sync controller 107 may determine (at 106) that UE101 has moved into, or toward, geographical region 103-2, and that MEC105-2 should be selected or assigned to provide services relating to theapplication executed by UE 101. Additionally, or alternatively, asdiscussed above, MEC sync controller 107 may select MEC 105-2 based onone or more other factors in addition to, or in lieu of, UE 101 movinginto or toward geographical region 103-2.

Based on assigning, selecting, etc. MEC 105-2, MEC sync controller 107may output (at 108) locator information associated with MEC 105-2 to UE101. For example, as discussed below, UE 101 may implement one or moreapplication programming interfaces (“APIs”), applications, or othersuitable communication pathways via which UE 101 may communicate withMEC sync controller 107. The locator information may include an InternetProtocol (“IP”) address of MEC 105-2, a hostname of MEC 105-2, anidentifier of MEC 105-2, and/or some other information via which UE 101may communicate with MEC 105-2. In some embodiments, MEC sync controller107 may provide (at 108) an instruction to communicate with MEC 105-2instead of with MEC 105-1, a MEC switch indication, and/or some othertype of indication to prepare to communicate with MEC 105-2. In someembodiments, MEC sync controller 107 may provide (at 108) anauthentication token or other type of security information, which may beused by UE 101 to facilitate a switch from communicating with MEC 105-1to MEC 150-2 with an elevated priority (e.g., in a seamless fashion).

Based on receiving the locator information, MEC switch indication, etc.,UE 101 may initiate (at 110) a sync of context data, associated with theapplication, with MEC 105-1. For example, MEC 105-1 may output (at 110)some or all context data, used by MEC 105-1 to perform computations orcalculations, or to otherwise provide services related to theapplication, to UE 101. In some embodiments, UE 101 and/or MEC 105-1 mayoutput a MEC switch indication to a base station and/or one or moreother network devices.

Based on the MEC switch indication, the base station or the one or moreother network devices may provide traffic, associated with the syncingof the context data to UE 101, with an elevated priority. For example,the base station may grant a relatively large amount of radio frequency(“RF”) resources (e.g., Physical Resource Blocks (“PRBs”)) and/or otherresources to UE 101 in order to ensure a relatively fast transfer of thecontext data to UE 101. For example, the “relatively large amount” ofresources may be an amount that is in excess of one or more Quality ofService (“QoS”) policies, Service Level Agreements (“SLAs”), or thelike, associated with UE 101 and/or the application. In someembodiments, the “relatively large amount” of resources may be, or maybebased on, a predetermined amount of resources that should be granted forsyncing of context data used by MEC 105-1. Additionally, oralternatively, the base station and/or other network devices mayincrease a queue weight or priority associated with the traffic based onthe MEC switch indication.

In some embodiments, MEC 105-1 may mark the traffic (e.g., include aflag in header information and/or some other type of indicator) with aMEC switch indication, indicating that the traffic is associated with asyncing of context data from MEC 105-1 to UE 101. Based on the MECswitch indication, the base station and/or other network devices mayprovide elevated priority to the traffic.

In some embodiments, the MEC switch indication may include the token orother authentication information provided by MEC sync controller 107.The base station or other network devices may validate the token priorto providing the elevated priority to the traffic. For example, the basestation or other network devices may request and/or may have previouslyreceived the token from MEC sync controller 107, and may compare thetokens to determine a match. In case of a match, the base station orother network devices may validate the token included in the MEC switchindication, and may provide the elevated priority to the traffic.

Once UE 101 has received the context data (at 110), UE 101 may provide(at 112) the context data to target MEC 105-2. In some embodiments, UE101 may cache some or all of the context data (e.g., in a local datastorage device of UE 101) until the context data has been fully providedto target MEC 105-2. As similarly discussed above, UE 101 may output aMEC switch indication or other type of request to a base stationassociated with MEC 105-2 and/or geographical region 103-2, and/or mayinclude the MEC switch indication in traffic (including the contextdata) sent to MEC 105-2, based on which the traffic may be treated withelevated priority.

Once MEC 105-2 has received the context data, MEC 105-2 may communicate(at 114) with UE 101 based on the received context data. For example,MEC 105-2 may “resume” providing services, associated with theapplication, that were previously provided by MEC 105-1. As noted above,such applications may include autonomous driving applications, ARapplications, gaming applications, and/or other types of applications.Due to the caching of the context data by UE 101, the transfer from MEC105-1 and/or to MEC 105-2, of the context data, may be faster thansyncing the context data with a central device or system that is moredistant from MECs 105-1 and 105-2 than UE 101 (e.g., in terms ofgeographical distance, latency, network hops, or other types ofdistance). Further, the elevated priority provided to such transfersover other types of traffic may ensure that the context data is notdelayed in favor of other types of traffic. In this manner, even ifcommunications between UE 101 and MECs 105-1 and/or 105-2 relating toapplication data (e.g., at 102 and/or 114) are subject to a particularset of priority rules (e.g., by which the may be lower priority trafficthan traffic associated with other UEs), an exception may be made forthe context data transfers (at 108 and/or 112).

FIG. 2 illustrates example components of UE 101, MECs 105-1 and/or105-2, and MEC sync controller 107, in accordance with some embodiments.As shown, for example, UE 101 may be associated with a set ofapplications 201, MEC sync agent—UE 203, and elevated priority agent205. Applications 201 may include one or more network applications thatsend and/or receive data to one or more device or systems via a network,such as a RAN. For example, applications 201 may receive user input,receive sensor data associated with one or more sensors of UE 101,and/or receive other information via UE 101, and may output some or allof the information to a given MEC (e.g., MEC 105-1 and/or MEC 105-2) viaa RAN. Additionally, or alternatively, applications 201 may communicatewith one or more other devices or systems (e.g., application serversand/or some other type of device or system) via the Internet and/or someother network.

Applications 201 may include “client-side” applications, while MECs105-1 and/or 105-2 may execute “server-side” applications application207-1 and 207-2, respectively. For example, a particular application 201may receive user input via UE 101, and may provide the user input(and/or information derived from or generated based on the user input)to an associated application 207-1 and/or 207-2, which may performcomputations, calculations, etc. (as described above) based on thereceived input, and may provide output (e.g., application traffic) toapplication 201. In turn, application 201 may present output information(e.g., graphics, sound, haptic feedback, etc.) based on the informationreceived from application 207-1 and/or 207-2.

MEC sync agent—UE 203 may communicate with MEC sync controller 107 viaan API or other suitable communication pathway. In some embodiments, MECsync agent—UE 203 may communicate with MEC sync controller 107 via theInternet and/or some other suitable network. As noted above, MEC synccontroller 107 may monitor a location of UE 101 and/or one or more otherfactors. Based on the location and/or other factors, MEC sync controller107 may select a particular MEC 105 to provide services to UE 101 (e.g.,which particular MEC 105, out of a candidate set of MECs 105, shouldimplement a particular application 207 to communicate with a particularapplication 201 executing on UE 101). MEC sync controller 107 mayprovide information to MEC sync agent—UE 203, indicating a particularMEC 105 with which UE 101 should communicate with (e.g., to which anetwork layer, operating system, and/or other suitable component of UE101 should route traffic associated with one or more applications 201).As noted above, the information may include an IP address, a UniformResource Locator (“URL”), a Uniform Resource Identifier (“URI”), ahostname, a MEC identifier, or other suitable locator for a particularselected MEC 105. For example, in instances where UE 101 (e.g.,applications 201) are presently communicating with applications 207-1 ofMEC 105-1, MEC sync controller 107 may output information to MEC syncagent—UE 203, indicating that UE 101 should communicate with MEC 105-2(e.g., applications 207-2) in lieu of MEC 105-1. In some embodiments,MEC sync controller 107 may provide such information with conditions,such as a condition that if UE 101 enters a particular geographicalregion, a coverage area associated with a particular base station,and/or other conditions, then UE 101 should communicate with MEC 105-2instead of with MEC 105-1.

MEC sync agent—UE 203 may also communicate with respective MEC syncagents—MEC 209-1 and/or MEC sync agent—MEC 209-2, associated with MECs105-1 and 105-2, respectively. For example, in the example where MECsync controller 107 instructs MEC sync agent—UE 203 to switch from MEC105-1 to MEC 105-2, MEC sync agent—UE 203 may output a request for syncinformation (e.g., application context information associated with oneor more applications 207-1) to MEC sync agent—MEC 209-1, and MEC syncagent—MEC 209-1 may provide the requested context information to MECsync agent—UE 203. MEC sync agent—UE 203 may store, cache, buffer, etc.the received sync information. Further, MEC sync agent—UE 203 mayprovide the context information to MEC sync agent—MEC 209-2, which mayprovide the context information to one or more applications 207-2.

Further, MEC sync agent—UE 203 may provide information regarding thecommunications with MECs 105-1 and 105-2 (e.g., the transfer of thecontext information from MEC 105-1 and/or to MEC 105-2) to elevatedpriority agent 205. For example, MEC sync agent—UE 203 may insert headerinformation (e.g., a flag, a marking, a label, etc.) indicating that thetraffic is associated with a context transfer, and may provide the flag,marking, etc. to elevated priority agent 205. Elevated priority agent205 may communicate with one or more elements of network 211, in orderto receive elevated priority treatment of the traffic sent between MECsync agent—UE 203 and MEC sync agents—MEC 209-1 and/or 209-2. Forexample, elevated priority agent 205 may communicate with a base stationof a RAN to which UE 101 is connected and/or one or more othercomponents of network 211, which may prioritize traffic with theindicated flag, marking, etc. Such prioritization may be different froma priority level associated with UE 101 and/or applications 201. Inother words, application traffic associated with applications 201 may beprioritized different from context transfer traffic associated with MECsync agent—UE 203 and MEC sync agents—MEC 209-1 and/or 209-2, thusproviding a seamless experience when switching from one MEC 105 toanother.

FIG. 3 illustrates an example signal flow that may be used for aseamless transfer between MECs, in accordance with some embodiments. Asshown, for example, UE 101 (e.g., MEC sync agent—UE 203) may receive (at302) in indication to switch to MEC 105-2. As noted above, thisindication may include an IP address, a URL, and/or other suitableidentifier of MEC 105-2, which UE 101 may use to communicate with MEC105-2. Based on receiving (at 302) the indication to switch to MEC105-2, UE 101 (e.g., MEC sync agent—UE 203) may output (at 304) a MECswitch indication to MEC 105-1, with which UE 101 (e.g., one or moreapplications 201) is currently in communication.

MEC 105-1 may output (at 306) context data information, associated withone or more applications 201, to UE 101. The context data informationmay include a size or amount of context data, a location or addressassociated with MEC 105-1 from which UE 101 may access the context data,and/or other descriptors of the context data. UE 101 (e.g., elevatedpriority agent 205) may communicate (e.g., via a control channel orother suitable interface) with one or more devices or systems associatedwith network 211, in order to request (at 308) elevated priority for aMEC data sync (e.g., the transferring of context information from MEC105-1 to UE 101, and from UE 101 to MEC 105-2). As noted above, therequest (at 308) may include information that network 211 may use toidentify the transfer of the context information, such as one or moreflags, labels, etc.

UE 101 may also provide (at 310) information regarding the context data,such as size, file type(s), application identifiers, or the like, to MEC105-2. MEC 105-2 may, in some embodiments, provision, free up, etc.storage space to accommodate the context data, and/or may instantiate,install, provision, etc. one or more applications 207 with which thecontext data is associated. MEC 105-2 may provide (at 312) locatorinformation, such as an IP address, a URL, directory information, orother suitable information which may be used by UE 101 (e.g., MEC syncagent—UE 203) to provide the context information once received.

UE 101 may further receive (at 314) the context data from MEC 105-1. Forexample, UE 101 may output a confirmation to MEC 105-1 after receiving(at 312) locator information from MEC 105-2, based on which MEC 105-1may output (at 314) the context data to UE 101. In some embodiments, MEC105-1 may output (at 314) the context data to UE 101 independent of anysuch confirmation from UE 101. The context data may be provided (at 314)via a RAN associated with UE 101 and/or MEC 105-1, and may be providedwith elevated priority based on the request (at 308) provided by UE 101.For example, a base station associated with network 211 may provideextra PRBs for the context data, may increase a queue weight associatedthe context data, and/or otherwise prioritize the context data (e.g.,allot a higher priority than application traffic associated with UE 101and MEC 105-1).

UE 101 may cache (at 316) the received context data, and may provide (at318) the context data to MEC 105-2 (e.g., MEC sync agent—MEC 209-2). Forexample, UE 101 may use the context data locator information provided(at 312) by MEC 105-2. As similarly noted above, the context data may beprovided (at 318) with elevated priority, to ensure a seamless transferof services between MEC 105-1 and 105-2.

FIG. 4 illustrates an example process 400 for a seamless transferbetween MECs 105, in accordance with some embodiments. In someembodiments, some or all of process 400 may be performed by UE 101(e.g., by MEC sync agent—UE 203 and/or elevated priority agent 205). Insome embodiments, one or more other devices may perform some or all ofprocess 400 (e.g., in concert with, and/or in lieu of, UE 101).

As shown, process 400 may include receiving (at 402) services from asource MEC. For example, UE 101 may communicate with a first MEC 105-1,which may execute one or more “server side” applications 207 thatcommunicate with one or more “client side” applications 201 executing atUE 101.

Process 400 may further include receiving (at 404) a MEC switchindication. For example, UE 101 may receive the MEC switch indicationfrom MEC sync controller 107. For example, MEC sync controller 107 mayhave determined, based on a geographical location of UE 101 and/or oneor more other factors, that UE 101 should communicate with a second MEC105-2 (e.g., a “target” MEC).

Process 400 may further include identifying (at 406) context dataparameters associated with the one or more applications 207 executing atMEC 105-1. For example, UE 101 may request information regarding a sizeof the context data associated with applications 207, file types of thecontext data, and/or other suitable parameters. As noted above, UE 101(e.g., MEC sync agent—UE 203) may request such information from MEC105-1 (e.g., MEC sync agent—MEC 209-1 associated with MEC 105-1).

Process 400 may additionally include requesting (at 408) elevatednetwork priority for a transfer of the context data based on the contextdata parameters. For example, UE 101 (e.g., elevated priority agent 205)may output a request to a base station to which UE 101 is connectedand/or to some other network element, indicating the size, file type(s),flags and/or labels, and/or other parameters associated with thetransfer of the context data to UE 101 (e.g., from MEC 105-1) and/orfrom UE 101 (e.g., to MEC 105-2).

Process 400 may also include obtaining (at 410) storage locationinformation associated with MEC 105-2. For example, UE 101 (e.g., MECsync agent—UE 203) may communicate with MEC 105-2 (e.g., MEC syncagent—MEC 209-2) to identify an IP address, a URL, and/or otherinformation that may be used by UE 101 to provide the context associatedwith applications 207-1 executing at MEC 105-1 (e.g.,“server side”applications 207 associated with one or more “client side” applications201 executing at UE 101). In some embodiments, the storage location mayinclude one or more storage devices implemented by the same set ofhardware as MEC 105-2 (e.g., the same data center, the same server orserver racks, the same cloud computing system, etc.).

Process 400 may further include receiving (at 412) context data from MEC105-1. For example, UE 101 may output a request for the context data(e.g., after receiving the storage location information from MEC 105-2and/or at some other time). In some embodiments, MEC 105-1 may providethe context data after receiving (at 406) a request for context dataparameters and/or at some other time that is independent of UE 101receiving the storage location information from MEC 105-2. As notedabove, traffic associated with the context data may be treated withelevated priority by one or more network elements via which the trafficis provided, based on the request (at 408) for elevated network priorityfor the context data transfer.

Process 400 may additionally include outputting (at 414) the contextdata to the storage location associated with MEC 105-2. For example, UE101 may output the context data (received at 412) to the storagelocation (e.g., as indicated at 410) associated with MEC 105-2. MEC105-2 may instantiate, activate, etc. one or more instances ofapplications 207, with which the context data is associated with, basedon receiving the context data (at 414) and/or based on receiving someother indication of the transfer (e.g., the request at 410 for thestorage location information associated with MEC 105-2). As noted above,traffic associated with the context data may be treated with elevatedpriority by one or more network elements via which the traffic isprovided, based on the request (at 408) for elevated network priorityfor the context data transfer.

Process 400 may also include receiving services (at 416) from MEC 105-2.For example, MEC 105-2 may “resume” operations, via applications 207-2,that were previously performed by applications 207-1 associated with MEC105-1, using the context data provided by UE 101. In this manner, UE 101may receive a “seamless” experience of the network applications 201executing on UE 101, with minimal or no disruption of MEC-providedservices for applications 201 (e.g., as provided by MECs 105-1 and105-2).

FIG. 5 illustrates an example environment 500, in which one or moreembodiments may be implemented. In some embodiments, environment 500 maycorrespond to a 5G network, and/or may include elements of a 5G network.In some embodiments, environment 500 may correspond to a 5GNon-Standalone (“NSA”) architecture, in which a 5G radio accesstechnology (“RAT”) may be used in conjunction with one or more otherRATs (e.g., a LTE RAT), and/or in which elements of a 5G core networkmay be implemented by, may be communicatively coupled with, and/or mayinclude elements of another type of core network (e.g., an evolvedpacket core (“EPC”)). As shown, environment 500 may include UE 101, RAN510 (which may include one or more Next Generation Node Bs (“gNBs”)511), RAN 512 (which may include one or more one or more evolved Node Bs(“eNBs”) 513), and various network functions such as Access and MobilityManagement Function (“AMF”) 515, Mobility Management Entity (“MME”) 516,Serving Gateway (“SGW”) 517, Session Management Function (“SMF”)/PacketData Network (“PDN”) Gateway (“PGW”)—Control plane function (“PGW-C”)520, Policy Control Function (“PCF”)/Policy Charging and Rules Function(“PCRF”) 525, Application Function (“AF”) 530, User Plane Function(“UPF”)/PGW—User plane function (“PGW-U”) 535, Home Subscriber Server(“HSS”)/Unified Data Management (“UDM”) 540, and Authentication ServerFunction (“AUSF”) 545. Environment 500 may also include one or morenetworks, such as Data Network (“DN”) 550. Environment 500 may includeone or more additional devices or systems communicatively coupled to oneor more networks (e.g., DN 550), such as MEC sync controller 107.

The example shown in FIG. 5 illustrates one instance of each networkcomponent or function (e.g., one instance of SMF/PGW-C 520, PCF/PCRF525, UPF/PGW-U 535, HSS/UDM 540, and/or 545). In practice, environment500 may include multiple instances of such components or functions. Forexample, in some embodiments, environment 500 may include multiple“slices” of a core network, where each slice includes a discrete set ofnetwork functions (e.g., one slice may include a first instance ofSMF/PGW-C 520, PCF/PCRF 525, UPF/PGW-U 535, HSS/UDM 540, and/or 545,while another slice may include a second instance of SMF/PGW-C 520,PCF/PCRF 525, UPF/PGW-U 535, HSS/UDM 540, and/or 545). The differentslices may provide differentiated levels of service, such as service inaccordance with different Quality of Service (“QoS”) parameters.

The quantity of devices and/or networks, illustrated in FIG. 5, isprovided for explanatory purposes only. In practice, environment 500 mayinclude additional devices and/or networks, fewer devices and/ornetworks, different devices and/or networks, or differently arrangeddevices and/or networks than illustrated in FIG. 5. For example, whilenot shown, environment 500 may include devices that facilitate or enablecommunication between various components shown in environment 500, suchas routers, modems, gateways, switches, hubs, etc. Alternatively, oradditionally, one or more of the devices of environment 500 may performone or more network functions described as being performed by anotherone or more of the devices of environment 500. Devices of environment500 may interconnect with each other and/or other devices via wiredconnections, wireless connections, or a combination of wired andwireless connections. In some implementations, one or more devices ofenvironment 500 may be physically integrated in, and/or may bephysically attached to, one or more other devices of environment 500.

UE 101 may include a computation and communication device, such as awireless mobile communication device that is capable of communicatingwith RAN 510, RAN 512, and/or DN 550. UE 101 may be, or may include, aradiotelephone, a personal communications system (“PCS”) terminal (e.g.,a device that combines a cellular radiotelephone with data processingand data communications capabilities), a personal digital assistant(“PDA”) (e.g., a device that may include a radiotelephone, a pager,Internet/intranet access, etc.), a smart phone, a laptop computer, atablet computer, a camera, a personal gaming system, an IoT device(e.g., a sensor, a smart home appliance, or the like), a wearabledevice, an IoT device, M2M device, or another type of mobile computationand communication device. UE 101 may send traffic to and/or receivetraffic (e.g., user plane traffic) from DN 550 via RAN 510, RAN 512,and/or UPF/PGW-U 535.

RAN 510 may be, or may include, a 5G RAN that includes one or more basestations (e.g., one or more gNBs 511), via which UE 101 may communicatewith one or more other elements of environment 500. UE 101 maycommunicate with RAN 510 via an air interface (e.g., as provided by gNB511). For instance, RAN 510 may receive traffic (e.g., voice calltraffic, data traffic, messaging traffic, signaling traffic, etc.) fromUE 101 via the air interface, and may communicate the traffic toUPF/PGW-U 535, and/or one or more other devices or networks. Similarly,RAN 510 may receive traffic intended for UE 101 (e.g., from UPF/PGW-U535, AMF 515, and/or one or more other devices or networks) and maycommunicate the traffic to UE 101 via the air interface.

RAN 512 may be, or may include, a LTE RAN that includes one or more basestations (e.g., one or more eNBs 513), via which UE 101 may communicatewith one or more other elements of environment 500. UE 101 maycommunicate with RAN 512 via an air interface (e.g., as provided by eNB513). For instance, RAN 510 may receive traffic (e.g., voice calltraffic, data traffic, messaging traffic, signaling traffic, etc.) fromUE 101 via the air interface, and may communicate the traffic toUPF/PGW-U 535, and/or one or more other devices or networks. Similarly,RAN 510 may receive traffic intended for UE 101 (e.g., from UPF/PGW-U535, SGW 517, and/or one or more other devices or networks) and maycommunicate the traffic to UE 101 via the air interface.

AMF 515 may include one or more devices, systems, Virtualized NetworkFunctions (“VNFs”), etc., that perform operations to register UE 101with the 5G network, to establish bearer channels associated with asession with UE 101, to hand off UE 101 from the 5G network to anothernetwork, to hand off UE 101 from the other network to the 5G network,manage mobility of UE 101 between RANs 510 and/or gNBs 511, and/or toperform other operations. In some embodiments, the 5G network mayinclude multiple AMFs 515, which communicate with each other via the N14interface (denoted in FIG. 5 by the line marked “N14” originating andterminating at AMF 515).

MME 516 may include one or more devices, systems, VNFs, etc., thatperform operations to register UE 101 with the EPC, to establish bearerchannels associated with a session with UE 101, to hand off UE 101 fromthe EPC to another network, to hand off UE 101 from another network tothe EPC, manage mobility of UE 101 between RANs 512 and/or eNBs 513,and/or to perform other operations.

SGW 517 may include one or more devices, systems, VNFs, etc., thataggregate traffic received from one or more eNBs 513 and send theaggregated traffic to an external network or device via UPF/PGW-U 535.Additionally, SGW 517 may aggregate traffic received from one or moreUPF/PGW-Us 535 and may send the aggregated traffic to one or more eNBs513. SGW 517 may operate as an anchor for the user plane duringinter-eNB handovers and as an anchor for mobility between differenttelecommunication networks or RANs (e.g., RANs 510 and 512).

SMF/PGW-C 520 may include one or more devices, systems, VNFs, etc., thatgather, process, store, and/or provide information in a manner describedherein. SMF/PGW-C 520 may, for example, facilitate in the establishmentof communication sessions on behalf of UE 101. In some embodiments, theestablishment of communications sessions may be performed in accordancewith one or more policies provided by PCF/PCRF 525.

PCF/PCRF 525 may include one or more devices, systems, VNFs, etc., thataggregate information to and from the 5G network and/or other sources.PCF/PCRF 525 may receive information regarding policies and/orsubscriptions from one or more sources, such as subscriber databasesand/or from one or more users (such as, for example, an administratorassociated with PCF/PCRF 525).

AF 530 may include one or more devices, systems, VNFs, etc., thatreceive, store, and/or provide information that may be used indetermining parameters (e.g., quality of service parameters, chargingparameters, or the like) for certain applications.

UPF/PGW-U 535 may include one or more devices, systems, VNFs, etc., thatreceive, store, and/or provide data (e.g., user plane data). Forexample, UPF/PGW-U 535 may receive user plane data (e.g., voice calltraffic, data traffic, etc.), destined for UE 101, from DN 550, and mayforward the user plane data toward UE 101 (e.g., via RAN 510, SMF/PGW-C520, and/or one or more other devices). In some embodiments, multipleUPFs 535 may be deployed (e.g., in different geographical locations),and the delivery of content to UE 101 may be coordinated via the N9interface (e.g., as denoted in FIG. 5 by the line marked “N9”originating and terminating at UPF/PGW-U 535). Similarly, UPF/PGW-U 535may receive traffic from UE 101 (e.g., via RAN 510, SMF/PGW-C 520,and/or one or more other devices), and may forward the traffic toward DN550. In some embodiments, UPF/PGW-U 535 may communicate (e.g., via theN4 interface) with SMF/PGW-C 520, regarding user plane data processed byUPF/PGW-U 535.

HSS/UDM 540 and AUSF 545 may include one or more devices, systems, VNFs,etc., that manage, update, and/or store, in one or more memory devicesassociated with AUSF 545 and/or HSS/UDM 540, profile informationassociated with a subscriber. AUSF 545 and/or HSS/UDM 540 may performauthentication, authorization, and/or accounting operations associatedwith the subscriber and/or a communication session with UE 101.

DN 550 may include one or more wired and/or wireless networks. Forexample, DN 550 may include an IP-based PDN, a wide area network (“WAN”)such as the Internet, a private enterprise network, and/or one or moreother networks. UE 101 may communicate, through DN 550, with dataservers, other UEs 101, and/or to other servers or applications that arecoupled to DN 550. DN 550 may be connected to one or more othernetworks, such as a public switched telephone network (“PSTN”), a publicland mobile network (“PLMN”), and/or another network. DN 550 may beconnected to one or more devices, such as content providers,applications, web servers, and/or other devices, with which UE 101 maycommunicate.

MEC sync controller 107 may receive, monitor, maintain, etc. informationregarding geographical locations of one or more UEs 501 and/or MECs 105.For example, MEC sync controller 107 may receive such information via aService Capability Exposure Function (“SCEF”), a Network ExposureFunction (“NEF”), or other suitable network element. In someembodiments, MEC sync controller 107 may select a particular MEC 105 toprovide services to UE 101 based on the geographical location of UE 101(e.g., proximity to a particular MEC 105) and/or other suitable factors(e.g., network and/or processing load of MECs 105, applicationsassociated with MECs 105, processing power associated with MECs 105,and/or other suitable factors). MEC sync controller 107 may output anindication to UE 101 (e.g., via DN 550, RAN 510, RAN 512, and/or someother suitable communication pathway) to switch to a particular MEC 501based on a determination that UE 101 has moved into a coverage areaassociated with the particular MEC 501 and/or based on other factors.

FIG. 6 illustrates an example Distributed Unit (“DU”) network 600, whichmay be included in and/or implemented by one or more RANs (e.g., RAN510, RAN 512, or some other RAN). In some embodiments, a particular RANmay include one DU network 600. In some embodiments, a particular RANmay include multiple DU networks 600. In some embodiments, DU network600 may correspond to a particular gNB 511 of a 5G RAN (e.g., RAN 510).In some embodiments, DU network 600 may correspond to multiple gNBs 511.In some embodiments, DU network 600 may correspond to one or more othertypes of base stations of one or more other types of RANs. As shown, DUnetwork 600 may include Central Unit (“CU”) 605, one or more DistributedUnits (“DUs”) 603-1 through 603-N (referred to individually as “DU 603,”or collectively as “DUs 603”), and one or more Radio Units (“RUs”) 601-1through 601-M (referred to individually as “RU 601,” or collectively as“RUs 601”).

CU 605 may communicate with a core of a wireless network (e.g., maycommunicate with one or more of the devices or systems described abovewith respect to FIG. 5, such as AMF 515 and/or UPF/PGW-U 535). In theuplink direction (e.g., for traffic from UEs 101 to a core network), CU605 may aggregate traffic from DUs 603, and forward the aggregatedtraffic to the core network. In some embodiments, CU 605 may receivetraffic according to a given protocol (e.g., Radio Link Control (“RLC”))from DUs 603, and may perform higher-layer processing (e.g., mayaggregate/process RLC packets and generate Packet Data ConvergenceProtocol (“PDCP”) packets based on the RLC packets) on the trafficreceived from DUs 603.

In accordance with some embodiments, CU 605 may receive downlink traffic(e.g., traffic from the core network) for a particular UE 101, and maydetermine which DU(s) 603 should receive the downlink traffic. DU 603may include one or more devices that transmit traffic between a corenetwork (e.g., via CU 605) and UE 101 (e.g., via a respective RU 601).DU 603 may, for example, receive traffic from RU 601 at a first layer(e.g., physical (“PHY”) layer traffic, or lower PHY layer traffic), andmay process/aggregate the traffic to a second layer (e.g., upper PHYand/or RLC). DU 603 may receive traffic from CU 605 at the second layer,may process the traffic to the first layer, and provide the processedtraffic to a respective RU 601 for transmission to UE 101.

RU 601 may include hardware circuitry (e.g., one or more RFtransceivers, antennas, radios, and/or other suitable hardware) tocommunicate wirelessly (e.g., via an RF interface) with one or more UEs101, one or more other DUs 603 (e.g., via RUs 601 associated with DUs603), and/or any other suitable type of device. In the uplink direction,RU 601 may receive traffic from UE 101 and/or another DU 603 via the RFinterface and may provide the traffic to DU 603. In the downlinkdirection, RU 601 may receive traffic from DU 603, and may provide thetraffic to UE 101 and/or another DU 603.

RUs 601 may, in some embodiments, be communicatively coupled to one ormore MECs 105. For example, RU 601-1 may be communicatively coupled toMEC 105-1, RU 601-M may be communicatively coupled to MEC 105-M, DU603-1 may be communicatively coupled to MEC 105-2, DU 603-N may becommunicatively coupled to MEC 105-N, CU 605 may be communicativelycoupled to MEC 105-3, and so on. MECs 105 may include hardware resources(e.g., configurable or provisionable hardware resources) that may beconfigured to provide services and/or otherwise process traffic toand/or from UE 101, via a respective RU 601.

As noted above, MECs 105 may provide services to one or more UEs 101,such as by executing one or more applications 207 (e.g., “server side”applications). Further, MECs 105 may implement one or more instances ofMEC sync agent—MEC 209, via which MECs 105 may participate in seamlesstransfers of context data associated with applications 207 and one ormore UEs 101 (e.g., “client side” applications 201 executed by UEs 101).

For example, RU 601-1 may route some traffic, from UE 101, to MEC 105-1instead of to a core network (e.g., via DU 603 and CU 605). MEC 105-1may process the traffic, perform one or more computations based on thereceived traffic, and may provide traffic to UE 101 via RU 601-1. Inthis manner, ultra-low latency services may be provided to UE 101, astraffic does not need to traverse DU 603, CU 605, and an interveningbackhaul network between DU network 600 and the core network.

FIG. 7 illustrates an example O-RAN environment 700, which maycorrespond to RAN 510, RAN 512, and/or DU network 600. For example, RAN510, RAN 512, and/or DU network 600 may include one or more instances ofO-RAN environment 700, and/or one or more instances of O-RAN environment700 may implement RAN 510, RAN 512, DU network 600, and/or some portionthereof. As shown, O-RAN environment 700 may include Non-Real Time RadioIntelligent Controller (“RIC”) 701, Near-Real Time RIC 703, O-eNB 705,O-CU-Control Plane (“O-CU-CP”) 707, O-CU-User Plane (“O-CU-UP”) 709,O-DU 711, O-RU 713, and O-Cloud 715. In some embodiments, O-RANenvironment 700 may include additional, fewer, different, and/ordifferently arranged components.

In some embodiments, some or all of the elements of O-RAN environment700 may be implemented by one or more configurable or provisionableresources, such as virtual machines, cloud computing systems, physicalservers, and/or other types of configurable or provisionable resources.In some embodiments, some or all of O-RAN environment 700 may beimplemented by, and/or communicatively coupled to, one or more MECs 105.

Non-Real Time RIC 701 and Near-Real Time RIC 703 may receive performanceinformation (and/or other types of information) from one or moresources, and may configure other elements of O-RAN environment 700 basedon such performance or other information. For example, Near-Real TimeRIC 703 may receive performance information, via one or more E2interfaces, from O-eNB 705, O-CU-CP 707, and/or O-CU-UP 709, and maymodify parameters associated with O-eNB 705, O-CU-CP 707, and/or O-CU-UP709 based on such performance information. Similarly, Non-Real Time RIC701 may receive performance information associated with O-eNB 705,O-CU-CP 707, O-CU-UP 709, and/or one or more other elements of O-RANenvironment 700 and may utilize machine learning and/or other higherlevel computing or processing to determine modifications to theconfiguration of O-eNB 705, O-CU-CP 707, O-CU-UP 709, and/or otherelements of O-RAN environment 700. In some embodiments, Non-Real TimeRIC 701 may generate machine learning models based on performanceinformation associated with O-RAN environment 700 or other sources, andmay provide such models to Near-Real Time RIC 703 for implementation.

O-eNB 705 may perform functions similar to those described above withrespect to eNB 513. For example, O-eNB 705 may facilitate wirelesscommunications between UE 101 and a core network. O-CU-CP 707 mayperform control plane signaling to coordinate the aggregation and/ordistribution of traffic via one or more DUs 603, which may includeand/or be implemented by one or more O-DUs 711, and O-CU-UP 709 mayperform the aggregation and/or distribution of traffic via such DUs 603(e.g., O-DUs 711). O-DU 711 may be communicatively coupled to one ormore RUs 601, which may include and/or may be implemented by one or moreO-RUs 713. In some embodiments, O-Cloud 715 may include or beimplemented by one or more MECs 105, which may provide services, and maybe communicatively coupled, to O-CU-CP 707, O-CU-UP 709, O-DU 711,and/or O-RU 713 (e.g., via an O1 and/or O2 interface).

FIG. 8 illustrates example components of device 800. One or more of thedevices described above may include one or more devices 800. Device 800may include bus 810, processor 820, memory 830, input component 840,output component 850, and communication interface 860. In anotherimplementation, device 800 may include additional, fewer, different, ordifferently arranged components.

Bus 810 may include one or more communication paths that permitcommunication among the components of device 800. Processor 820 mayinclude a processor, microprocessor, or processing logic that mayinterpret and execute instructions. Memory 830 may include any type ofdynamic storage device that may store information and instructions forexecution by processor 820, and/or any type of non-volatile storagedevice that may store information for use by processor 820.

Input component 840 may include a mechanism that permits an operator toinput information to device 800 and/or other receives or detects inputfrom a source external to 840, such as a touchpad, a touchscreen, akeyboard, a keypad, a button, a switch, a microphone or other audioinput component, etc. In some embodiments, input component 840 mayinclude, or may be communicatively coupled to, one or more sensors, suchas a motion sensor (e.g., which may be or may include a gyroscope,accelerometer, or the like), a location sensor (e.g., a GlobalPositioning System (“GPS”)—based location sensor or some other suitabletype of location sensor or location determination component), athermometer, a barometer, and/or some other type of sensor. Outputcomponent 850 may include a mechanism that outputs information to theoperator, such as a display, a speaker, one or more light emittingdiodes (“LEDs”), etc.

Communication interface 860 may include any transceiver-like mechanismthat enables device 800 to communicate with other devices and/orsystems. For example, communication interface 860 may include anEthernet interface, an optical interface, a coaxial interface, or thelike. Communication interface 860 may include a wireless communicationdevice, such as an infrared (“IR”) receiver, a Bluetooth²⁰⁰ radio, orthe like. The wireless communication device may be coupled to anexternal device, such as a remote control, a wireless keyboard, a mobiletelephone, etc. In some embodiments, device 800 may include more thanone communication interface 860. For instance, device 800 may include anoptical interface and an Ethernet interface.

Device 800 may perform certain operations relating to one or moreprocesses described above. Device 800 may perform these operations inresponse to processor 820 executing software instructions stored in acomputer-readable medium, such as memory 830. A computer-readable mediummay be defined as a non-transitory memory device. A memory device mayinclude space within a single physical memory device or spread acrossmultiple physical memory devices. The software instructions may be readinto memory 830 from another computer-readable medium or from anotherdevice. The software instructions stored in memory 830 may causeprocessor 820 to perform processes described herein. Alternatively,hardwired circuitry may be used in place of or in combination withsoftware instructions to implement processes described herein. Thus,implementations described herein are not limited to any specificcombination of hardware circuitry and software.

The foregoing description of implementations provides illustration anddescription, but is not intended to be exhaustive or to limit thepossible implementations to the precise form disclosed. Modificationsand variations are possible in light of the above disclosure or may beacquired from practice of the implementations.

For example, while series of blocks and/or signals have been describedabove (e.g., with regard to FIGS. 1-4), the order of the blocks and/orsignals may be modified in other implementations. Further, non-dependentblocks and/or signals may be performed in parallel. Additionally, whilethe figures have been described in the context of particular devicesperforming particular acts, in practice, one or more other devices mayperform some or all of these acts in lieu of, or in addition to, theabove-mentioned devices.

The actual software code or specialized control hardware used toimplement an embodiment is not limiting of the embodiment. Thus, theoperation and behavior of the embodiment has been described withoutreference to the specific software code, it being understood thatsoftware and control hardware may be designed based on the descriptionherein.

In the preceding specification, various example embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims thatfollow. The specification and drawings are accordingly to be regarded inan illustrative rather than restrictive sense.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the possible implementations. Infact, many of these features may be combined in ways not specificallyrecited in the claims and/or disclosed in the specification. Althougheach dependent claim listed below may directly depend on only one otherclaim, the disclosure of the possible implementations includes eachdependent claim in combination with every other claim in the claim set.

Further, while certain connections or devices are shown, in practice,additional, fewer, or different, connections or devices may be used.Furthermore, while various devices and networks are shown separately, inpractice, the functionality of multiple devices may be performed by asingle device, or the functionality of one device may be performed bymultiple devices. Further, multiple ones of the illustrated networks maybe included in a single network, or a particular network may includemultiple networks. Further, while some devices are shown ascommunicating with a network, some such devices may be incorporated, inwhole or in part, as a part of the network.

To the extent the aforementioned implementations collect, store, oremploy personal information of individuals, groups or other entities, itshould be understood that such information shall be used in accordancewith all applicable laws concerning protection of personal information.Additionally, the collection, storage, and use of such information canbe subject to consent of the individual to such activity, for example,through well known “opt-in” or “opt-out” processes as can be appropriatefor the situation and type of information. Storage and use of personalinformation can be in an appropriately secure manner reflective of thetype of information, for example, through various access control,encryption and anonymization techniques for particularly sensitiveinformation.

No element, act, or instruction used in the present application shouldbe construed as critical or essential unless explicitly described assuch. An instance of the use of the term “and,” as used herein, does notnecessarily preclude the interpretation that the phrase “and/or” wasintended in that instance. Similarly, an instance of the use of the term“or,” as used herein, does not necessarily preclude the interpretationthat the phrase “and/or” was intended in that instance. Also, as usedherein, the article “a” is intended to include one or more items, andmay be used interchangeably with the phrase “one or more.” Where onlyone item is intended, the terms “one,” “single,” “only,” or similarlanguage is used. Further, the phrase “based on” is intended to mean“based, at least in part, on” unless explicitly stated otherwise.

What is claimed is:
 1. A device, comprising: one or more processors configured to: receive services associated with a set of applications from a first Multi-Access/Mobile Edge Computing device (“MEC”); receive an indication to switch to a second MEC; receive context data, associated with the set of applications, from the first MEC; provide the context data to the second MEC; and receive, based on providing the context data to the second MEC, services associated with the set of applications from the second MEC.
 2. The device of claim 1, wherein the indication to switch to the second MEC is based on movement of the device from a first a geographical location associated with the first MEC toward a second geographical location associated with the second MEC.
 3. The device of claim 1, wherein the one or more processors are further configured to: output a request to elevate a priority associated with receiving the context data from the first MEC, wherein one or more network devices via which the context data is provided from the first MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data from the first MEC.
 4. The device of claim 3, wherein elevating the priority associated with receiving the context data from the first MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by the first MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output to the device, or increasing an amount of radio frequency (“RF”) resources granted to the device for transferring the context data from the first MEC.
 5. The device of claim 1, wherein the one or more processors are further configured to: output a request to elevate a priority associated with providing the context data to the second MEC, wherein one or more network devices via which the context data is provided to the second MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data to the second MEC.
 6. The device of claim 5, wherein elevating the priority associated with providing the context data to the second MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic provided to the second MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by the device, or increasing an amount of radio frequency (“RF”) resources granted to the device for transferring the context data to the second MEC.
 7. The device of claim 1, wherein the one or more processors are further configured to: receive, from the first MEC, information indicating an amount of context data associated with the set of applications; and provide, to the second MEC, an indication of the amount of context data associated with the set of applications.
 8. A non-transitory computer-readable medium, storing a plurality of processor-executable instructions to: receive services associated with a set of applications from a first Multi-Access/Mobile Edge Computing device (“MEC”); receive an indication to switch to a second MEC; receive context data, associated with the set of applications, from the first MEC; provide the context data to the second MEC; and receive, based on providing the context data to the second MEC, services associated with the set of applications from the second MEC.
 9. The non-transitory computer-readable medium of claim 8, wherein the indication to switch to the second MEC is based on movement of a device executing the processor-executable instructions from a first a geographical location associated with the first MEC toward a second geographical location associated with the second MEC.
 10. The non-transitory computer-readable medium of claim 8, wherein the plurality of processor-executable instructions further include processor-executable instructions to: output a request to elevate a priority associated with receiving the context data from the first MEC, wherein one or more network devices via which the context data is provided from the first MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data from the first MEC.
 11. The non-transitory computer-readable medium of claim 10, wherein elevating the priority associated with receiving the context data from the first MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by the first MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output to a device executing the processor-executable instructions, or increasing an amount of radio frequency (“RF”) resources granted to the device for transferring the context data from the first MEC.
 12. The non-transitory computer-readable medium of claim 8, wherein the plurality of processor-executable instructions further include processor-executable instructions to: output a request to elevate a priority associated with providing the context data to the second MEC, wherein one or more network devices via which the context data is provided to the second MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data to the second MEC.
 13. The non-transitory computer-readable medium of claim 12, wherein elevating the priority associated with providing the context data to the second MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic provided to the second MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by a device executing the processor-executable instructions, or increasing an amount of radio frequency (“RF”) resources granted to the device for transferring the context data to the second MEC.
 14. The non-transitory computer-readable medium of claim 8, wherein the plurality of processor-executable instructions further include processor-executable instructions to: receive, from the first MEC, information indicating an amount of context data associated with the set of applications; and provide, to the second MEC, an indication of the amount of context data associated with the set of applications.
 15. A method, comprising: receiving services associated with a set of applications from a first Multi-Access/Mobile Edge Computing device (“MEC”); receiving an indication to switch to a second MEC; receiving context data, associated with the set of applications, from the first MEC; providing the context data to the second MEC; and receiving, based on providing the context data to the second MEC, services associated with the set of applications from the second MEC.
 16. The method of claim 15, wherein the indication to switch to the second MEC is based on movement of a User Equipment (“UE”), receiving the services associated with the set of applications from the first MEC, from a first a geographical location associated with the first MEC toward a second geographical location associated with the second MEC.
 17. The method of claim 15, further comprising: outputting a request to elevate a priority associated with receiving the context data from the first MEC, wherein one or more network devices via which the context data is provided from the first MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data from the first MEC.
 18. The method of claim 17, wherein the context data is provided by the first MEC to a User Equipment (“UE”), wherein elevating the priority associated with receiving the context data from the first MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by the first MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output to the UE, or increasing an amount of radio frequency (“RF”) resources granted to the UE for transferring the context data from the first MEC.
 19. The method of claim 15, further comprising: outputting a request to elevate a priority associated with providing the context data to the second MEC, wherein one or more network devices via which the context data is provided to the second MEC prioritize the context data over other traffic based on the request to elevate the priority associated with the context data to the second MEC.
 20. The method of claim 19, wherein the context data is provided to the second MEC by a User Equipment (“UE”), wherein elevating the priority associated with providing the context data to the second MEC includes at least one of: increasing a queue weight of the context data, relative to a queue weight associated with other traffic provided to the second MEC, increasing a queue weight of the context data, relative to a queue weight associated with other traffic output by the UE, or increasing an amount of radio frequency (“RF”) resources granted to the UE for transferring the context data to the second MEC. 